개요

4.RESOURCE/KNOWLEDGE/AWS/AWS의 이벤트를 보는 리소스.
리소스가 생성된다거나, 조작되거나, 누가 접근했을 때라던가, 하는 모든 이벤트를 볼 수 있는 툴이라 보면 되겠다.
달리 말하자면 audit, 감사를 하는 툴이다.

클라우드트레일은 처음 계정이 만들어지는 순간부터 항상 존재한다.
그리고 별도의 설정을 하지 않더라도 event history를 통해 각종 이벤트들을 확인할 수 있으며, 비용이 발생하지 않는다.
다만 이 이벤트들은 90일이 지나면 삭제되니 저장이 필요한 이벤트라면 별도의 관리가 필요하다.

종류

클트는 다음의 세 가지 방식으로 이벤트를 볼 수 있도록 제공한다.
참고할 건 각각 독립적이라던가 한 게 아니다.
단순히 발생하는 이벤트들을 볼 수 있는 방식이 다르고 제공하는 기능이 다를 뿐이다.
event history로 보이는 것이 trail로 볼 수도 있다는 것!

event history

위에서 말했듯, 그냥 존재하는 이벤트 내역이다.
기본적으로는 리전 별로 존재하며, 영속적으로 저장되지 않는다.

cloudtrail lake

이벤트에 대한 데이터 레이크로, 캡처, 분석 등의 작업을 할 수 있다.
SQL라이크 쿼리를 사용하여 이벤트들을 정리하고 관리할 수 있다.
데이터 레이크가 데이터 엔지니어링적인 개념이라고는 알고 있지만, 자세히는 모르고 아직 써본 적도 없어서 이런 게 있다로만 치고 넘어가겠다.

trail

클라우드 트레일의 트레일(..).
event history로 보는 내용들을 S3에 저장하여 보는 방식으로, 트레일의 열화판이 event history라고도 볼 수 있을 듯.
트레일은 명시적으로 만들어야 쓸 수 있는데, 보통 세팅을 해두는 것을 추천한다.
이걸 써야 Amazon CloudWatch 로그로 넘길 수도 있고, Amazon EventBridge에 이벤트를 넘길 수도 있게 된다.
또한 멀티 리전으로 설정하는 것도 가능하고, 데이터를 Amazon KMS를 이용해 암호화할 수도 있다.
(기본 event history는 이벤트 브릿지로 넘어가지 않는다는 것을 몰라서 한참을 헤맸더랬다..)

리전 당 최대 5개를 만들 수 있고, 이 자체는 비용이 발생하지 않으나 s3 사용 비용과 cloudwatch로 넘기는 데에는 비용이 발생한다.

이벤트에 대해

그럼 어떤 식으로 이벤트들이 생겨먹었는지도 한번 보자.

{
    "eventVersion": "1.09",
    "userIdentity": {
        "type": "IAMUser",
        "principalId": "EXAMPLE6E4XEGITWATV6R",
        "arn": "arn:aws:iam::123456789012:user/Mary_Major",
        "accountId": "123456789012",
        "accessKeyId": "AKIAIOSFODNN7EXAMPLE",
        "userName": "Mary_Major",
        "sessionContext": {
            "attributes": {
                "creationDate": "2023-07-19T21:11:57Z",
                "mfaAuthenticated": "false"
            }
        }
    },
    "eventTime": "2023-07-19T21:33:41Z",
    "eventSource": "cloudtrail.amazonaws.com",
    "eventName": "StartLogging",
    "awsRegion": "us-east-1",
    "sourceIPAddress": "192.0.2.0",
    "userAgent": "aws-cli/2.13.5 Python/3.11.4 Linux/4.14.255-314-253.539.amzn2.x86_64 exec-env/CloudShell exe/x86_64.amzn.2 prompt/off command/cloudtrail.start-logging",
    "requestParameters": {
        "name": "myTrail"
    },
    "responseElements": null,
    "requestID": "9d478fc1-4f10-490f-a26b-EXAMPLE0e932",
    "eventID": "eae87c48-d421-4626-94f5-EXAMPLEac994",
    "readOnly": false,
    "eventType": "AwsApiCall",
    "managementEvent": true,
    "recipientAccountId": "123456789012",
    "eventCategory": "Management",
    "tlsDetails": {
        "tlsVersion": "TLSv1.2",
        "cipherSuite": "ECDHE-RSA-AES128-GCM-SHA256",
        "clientProvidedHostHeader": "cloudtrail.us-east-1.amazonaws.com"
    },
    "sessionCredentialFromConsole": "true"
}

이벤트는 json 형식으로 이렇게 생겨먹었다.
이 이벤트를 발동시킨 주체가 담겨있고, 원산지도 나온다.
readOnly와 managementEvent 필드가 뭔지는 아래 [[#이벤트 유형]]에서 보자.

이벤트 유형

여기에서 짚고 넘어갈 것은, aws에서 관리하는 이벤트의 유형이다.
유형 별로 각종 설정을 넣을 수 있기 때문에 그렇다.

Management event(관리 이벤트)

aws 계정 내에서 리소스 단위로 이뤄지는 이벤트들을 말한다.
aws의 api를 사용하는 이벤트들이 대표적이라 할 수 있고, 아니면 콘솔 로그인 등의 보편적인 감사 관련 이벤트들이 여기에 해당된다.
이것들은 기본적인 이벤트로 간주된다.

이 이벤트들은 또 세부적으로 읽기 이벤트(ReadOnly: true), 쓰기 이벤트(ReadOnly: false)로 나눌 수 있다.
이를 나누어서 이벤트를 남기는 것이 가능하다.

Data event(데이터 이벤트)

...
    "readOnly": false,
    ...
    "managementEvent": false,
    "eventCategory": "Data",
...

리소스에 대해서 일어나는 이벤트가 아닌, 리소스 안 속에서 행해지는 조작에 대한 이벤트들이다.
예를 들면 이런 것들이 있다.

• s3 오브젝트 레벨에서 일어나는 api 활동
  • get object, put object 등 단일 버켓에서 일어나는 작업들
• Amazon Lambda 함수 실행 활동
• Amazon DynamoDB 테이블에 대해서 일어나는 활동

이런 것들은 관리 이벤트에 비해서 엄청나게 많이 발생할 수 있으며, 기본적으로는 트레일에 담기지 않는다.
하지만 이걸 담고 싶다면 설정을 할 수 있다.

다만 비용은 감수할 생각을 해야 한다.
관리 이벤트와 비교해서 싸보이는데, 실제로 발생하는 이벤트 개수로 치자면 데이터 이벤트는 ㅎㄷㄷ할 가능성이 높다.
그러니 정말 필요한 데이터 이벤트에 대해서만 설정을 하는 것이 좋겠다.

Network activity event(네트워크 활동 이벤트)

VPC에서 일어나는 네트워크 활동에 대한 이벤트.
엔드포인트를 뚫어놨다고 쳤을 때, 이 엔드포인트에 접근하는 활동들을 이벤트로 남길 수 있다.
대표적으로 아래의 리소스들에 대해 이벤트를 남길 수 있다.

• cloudtrail
• EC2
• Amazon KMS
• S3

이것 역시 명시적으로 설정을 해줘야 한다.

Insight event(인사이트 이벤트)

비정상적인 활동, 에러 등의 활동에 대한 별도의 이벤트이다.
갑자기 비정상적으로 로그인이 많이 일어났다던가, 트래픽이 다량 발생했다던가.
평소에 내 계정이 s3를 1분에 최대 20개의 버켓을 지우는 행위가 이뤄져왔는데 갑자기 100개의 s3 버켓을 한꺼번에 지우는 활동이 포착된다던가, 평소와 다른 활동에 대해서 별도의 이벤트 처리를 해준다는 것이다.
이 이벤트 역시 명시적으로 설정을 해야만 이벤트로 받아볼 수 있다.

관련 문서

참고